pass --git-dir when reading git config when it was specified explicitly

Let GIT_DIR and --git-dir override git's protection against operating in a
repository owned by another user.

This is the same behavior other git commands have.

Sponsored-by: Jarkko Kniivilä on Patreon

Revert "fix comment"

This reverts commit c39b057b2daa3280c045d56d60b2c91a99a9c31b.

fix comment

comment

comment

changelog and close

note that hooks are also run when on a crippled filesystem now

remove unncessary do block

Left by Reiko's patch

Run freeze and thaw hooks on crippled filesystems

The user sets these hooks deliberately so they should always be run. For
example this allows hooks to be used to manage file permissions on NTFS
volumes in WSL1.

handle upgrading repositories initialized with --version=9

As was attempted earlier in the buggy commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85

Avoided the bug that had by making the upgrade log be updated after each
upgrade step. So, after upgrade from v8 to v9, the log is updated, and
so Upgrade.V9's timeOfUpgrade check will find that it was upgraded
recently and so won't let it skip ahead to v10.

Sponsored-by: k0ld on Patreon

changelog for problem fixed by earlier revert

comment

Revert "handle upgrading repositories initialized with --version=9"

This reverts commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85.

This commit accidentially caused repos that were initialized at v8 to
also upgrade to v10. There is nothing in the upgrade.log for such a
repo..

fix windows build

Merge branch 'master' of ssh://git-annex.branchable.com

report on windows FTBFS

Added a comment

Fix some markdown formatting problems

Add patches for WSL1

Fix WSL1 instructions

close bug "git commit smudges unncessarily"

Added a comment

refector for legibility

restage: New git-annex command, handles restaging unlocked files

This is much easier and less failure-prone than having the user run
git update-index --refresh themselves.

Sponsored-by: Dartmouth College's DANDI project

fix restaging of transferred files after stalldetection kicks in

Sponsored-by: Dartmouth College's DANDI project

add restage log

When pointer files need to be restaged, they're first written to the
log, and then when the restage operation runs, it reads the log. This
way, if the git-annex process is interrupted before it can do the
restaging, a later git-annex process can do it.

Currently, this lets a git-annex get/drop command be interrupted and
then re-ran, and as long as it gets/drops additional files, it will
clean up after the interrupted command. But more changes are
needed to make it easier to restage after an interrupted process.

Kept using the git queue to run the restage action, even though the
list of files that it builds up for that action is not actually used by
the action. This could perhaps be simplified to make restaging a cleanup
action that gets registered, rather than using the git queue for it. But
I wasn't sure if that would cause visible behavior changes, when eg
dropping a large number of files, currently the git queue flushes
periodically, and so it restages incrementally, rather than all at the
end.

In restagePointerFiles, it reads the restage log twice, once to get
the number of files and size, and a second time to process it.
This seemed better than reading the whole file into memory, since
potentially a huge number of files could be in there. Probably the OS
will cache the file in memory and there will not be much performance
impact. It might be better to keep running tallies in another file
though. But updating that atomically with the log seems hard.

Also note that it's possible for calcRestageLog to see a different file
than streamRestageLog does. More files may be added to the log in
between. That is ok, it will only cause the filterprocessfaster heuristic to
operate with slightly out of date information, so it may make the wrong
choice for the files that got added and be a little slower than ideal.

Sponsored-by: Dartmouth College's DANDI project

generalize refreshIndex to MonadIO

Sponsored-by: Dartmouth College's DANDI project

avoid unncessary locking by checkLogFile

Like the comment says, this works without locking. It looks like I
originally copied another function and forgot to remove the locking.

Sponsored-by: Dartmouth College's DANDI project

add a finalizer to streamLogFile

Sponsored-by: Dartmouth College's DANDI project

refactor the restage runner

Sponsored-by: Dartmouth College's DANDI project

Added a comment

test: Added --test-with-git-config option

Sponsored-by: Dartmouth College's DANDI project

comment and todo

Merge branch 'master' of ssh://git-annex.branchable.com

drain transferrer read handle when shutting it down

Fixes updating git index file after getting an unlocked file when
annex.stalldetection is set.

The transferrer may want to send additional protocol messages when it's
shut down. Closing the read handle prevented it from doing that, and caused
it to crash rather than cleanly shutting down.

Draining the handle without processing the protocol seemed ok to do,
because anything it outputs is going to be some side message displayed
at shutdown. Displaying those once per transferrer process that is running
seems unncessary.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

correct my comment

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

reproduced this now

reproduced this now

Merge branch 'master' of ssh://git-annex.branchable.com

Improved handling of --time-limit when combined with -J

When concurrency is enabled, there can be worker threads still running
when the time limit is checked. Exiting right there does not
give those threads time to finish what they're doing. Instead, the seeking
is wrapped up, and git-annex then shuts down cleanly.

The whole point of --time-limit existing, rather than using timeout(1)
when running git-annex is to let git-annex finish the action(s) it is
working on when the time limit is reached, and shut down cleanly.

I noticed this problem when investigating why restagePointerFile might
not have run after get/drop of an unlocked file. With --time-limit -J,
a worker thread may have finished updating a work tree file, and be killed
by the time limit check before it can run restagePointerFile. So despite
--time-limit running the shutdown actions, the work tree file didn't get
restaged.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

removed

Added a comment

Added a comment

Added a comment

Added a comment

comment

wording

comment

Merge branch 'master' of ssh://git-annex.branchable.com

annex.diskreserve default increased from 1 mb to 100 mb

It's hard to know what's a good default for this. But 1 mb seems way too
small, because it's very easy for a git pull or some similar operation
that we don't think of as using much space to use up 1 mb of space.

Most people would want to free up some space if a filesystem only had 100
mb free. But on a small VPS, it's probably not uncommon to have only 1 gb
free. So 1 gb is too large for annex.diskreserve.

While old 1 gb USB keys are around, it's unlikely that anyone is
relying on them to shuttle annex data around; it would be worth anyone's
time to upgrade to a 32 gb or larger cheap modern USB key ($5).

Sponsored-by: Kevin Mueller on Patreon

Added a comment

Added a comment

comment and todo

comment

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: "not inbackend=URL" is failed with parse error

Added a comment: "not inbackend=URL" is failed with parse error

Added a comment

initial report on odd "modified" status

Added a comment

Added a comment

wording

skip checkRepoConfigInaccessible when git directory specified explicitly

Fix a reversion that prevented git-annex from working in a repository when
--git-dir or GIT_DIR is specified to relocate the git directory to
somewhere else. (Introduced in version 10.20220525)

checkRepoConfigInaccessible could still run git config --list, just passing
--git-dir. It seems not necessary, because I know that passing --git-dir
bypasses git's check for repo ownership. I suppose it might be that git
eventually changes to check something about the ownership of the working
tree, so passing --git-dir without --work-tree would still be worth doing.
But for now this is the simple fix.

Sponsored-by: Nicholas Golder-Manning on Patreon

bug report rescued from forum

comment

comment

wontfix

comment

fixed

try retrieval from more than one export location when the first fails

Combined with commit 0ffc59d34107a3ee671b90fc7c59ca09c00abbf5, this
fixes the case where there are duplicate files on the special remote,
and the first gets modified/deleted, while the second is still present.

directory, adb: Fixed a bug when importtree=yes, and multiple files in the
special remote have the same content, that caused it to refuse to get a
file from the special remote, incorrectly complaining that it had changed,
due to only accepting the inode+mtime of one file (that was since modified
or deleted) and not accepting the inode+mtime of other duplicate files.

Sponsored-by: Max Thoursie on Patreon

change retrieveExportWithContentIdentifier to take a list of ContentIdentifier

This partly fixes an issue where there are duplicate files in the
special remote, and the first file gets swapped with another duplicate,
or deleted. The swap case is fixed by this, the deleted case will need
other changes.

This makes retrieveExportWithContentIdentifier take a list of allowed
ContentIdentifier, same as storeExportWithContentIdentifier,
removeExportWithContentIdentifier, and
checkPresentExportWithContentIdentifier.

Of the special remotes that support importtree, borg is a special case
and does not use content identifiers, S3 I assume can't get mixed up
like this, directory certainly has the problem, and adb also appears to
have had the problem.

Sponsored-by: Graham Spencer on Patreon

comment

comment

comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

deal with ignoreinode config setting

Improve handling of directory special remotes with importtree=yes whose
ignoreinode setting has been changed. (By either enableremote or by
upgrading to commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7.)

When getting a file from such a remote, accept the content that would have
been accepted with the previous ignoreinode setting.

After a change to ignoreinode, importing a tree from the remote will
re-import and generate new content identifiers using the new config. So
when ignoreinode has changed to no, the inodes will be learned, and after
that point, a change in an inode will be detected as a change. Before
re-importing, a change in an inode will be ignored, as it was before the
ignoreinode change. This seems acceptble, because the user can re-import
immediately if they urgently need to add inodes. And if not, they'll
do it sometime, presumably, and the change will take effect then.

Sponsored-by: Erik Bjäreholt on Patreon

comments

comment